Return false from == and nil from <=> for incomparable objects#31
Merged
Conversation
Unit subclasses Numeric, so == and <=> routed every non-Numeric operand through #apply_through_coercion, which re-raises as TypeError whenever the operand does not implement #coerce. That made ordinary expressions like `Unit(1) == nil` raise instead of returning false, breaking Ruby's contract that == never raises and that <=> returns nil for incomparable operands. Guard the coercion path with respond_to?(:coerce) so objects that opt into the coercion protocol (e.g. the UnitOne spec helper) still flow through it, while plain objects short-circuit: == returns false and <=> returns nil. Comparable then raises ArgumentError for ordered comparisons such as `Unit(1) > nil`, matching core Numeric behavior.
nertzy
added a commit
to nertzy/unit
that referenced
this pull request
Jun 12, 2026
Following minad#31, <=> returned nil for non-coercible objects, but the Numeric branch still raised IncompatibleUnitError (a TypeError) whenever two units had incompatible dimensions. Routed through Comparable that surfaced as the unhelpful "comparison of Unit with Unit failed", and sort, min, max, between? and clamp blew up with a non-standard error. Raise ArgumentError directly from <=> when the operands are dimensionally incompatible. Every Comparable path funnels through <=>, so the same descriptive message now surfaces from <, >, sort, min, max, between? and clamp. A sibling Unit is shown via #inspect (Unit("1 s")); any other numeric is shown by class (Float, Integer) rather than its coerced unit or a potentially large #inspect, matching core Ruby's own phrasing. Comparing against a genuinely foreign object (nil, String) still returns nil, matching 1 <=> "a"; only dimension mismatches between quantities raise. Arithmetic (+/-) keeps raising IncompatibleUnitError.
nertzy
added a commit
to nertzy/unit
that referenced
this pull request
Jun 12, 2026
Following minad#31, <=> returned nil for non-coercible objects, but the Numeric branch still raised IncompatibleUnitError (a TypeError) whenever two units had incompatible dimensions. Routed through Comparable that surfaced as the unhelpful "comparison of Unit with Unit failed", and sort, min, max, between? and clamp blew up with a non-standard error. Raise ArgumentError directly from <=> when the operands are dimensionally incompatible. Every Comparable path funnels through <=>, so the same descriptive message now surfaces from <, >, sort, min, max, between? and clamp. A sibling Unit is shown via #inspect (Unit("1 s")); any other numeric is shown by class (Float, Integer) rather than its coerced unit or a potentially large #inspect, matching core Ruby's own phrasing. Comparing against a genuinely foreign object (nil, String) still returns nil, matching 1 <=> "a"; only dimension mismatches between quantities raise. Arithmetic (+/-) keeps raising IncompatibleUnitError.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
UnitsubclassesNumeric, so==and<=>routed every non-Numericoperand through#apply_through_coercion, which re-raises asTypeErrorwhenever the operand doesn't implement#coerce. Ordinary expressions likeUnit(1) == nilraised instead of returningfalse, breaking Ruby's contract that==never raises and that<=>returnsnilfor incomparable operands.Guard the coercion path with
respond_to?(:coerce): objects that opt into the coercion protocol (e.g. theUnitOnespec helper) still flow through it, while plain objects short-circuit —==returnsfalseand<=>returnsnil.Comparablethen raisesArgumentErrorfor ordered comparisons likeUnit(1) > nil, matching coreNumericbehavior.Unit(1) == nilTypeErrorfalseUnit(1) != nilTypeErrortrueUnit(1) <=> nilTypeErrornilUnit(1) > nilTypeErrorArgumentError[Unit(1)].include?(nil)TypeErrorfalse